Target IP: 10.10.72.15
Challenge Description:
The "Publisher" CTF machine is a simulated environment hosting some services. Through a series of enumeration techniques, including directory fuzzing and version identification, a vulnerability is discovered, allowing for Remote Code Execution (RCE). Attempts to escalate privileges using a custom binary are hindered by restricted access to critical system files and directories, necessitating a deeper exploration into the system's security profile to ultimately exploit a loophole that enables the execution of an unconfined bash shell and achieve privilege escalation.
I performed a port scan using the command sudo nmap -sS 10.10.72.15 -p- and obtained the result shown above. By the looks of it, there are two TCP ports open on the target machine: SSH and HTTP on their standard ports. Time to perform an aggressive port scan against the two ports.
I performed an aggressive port scan using the command sudo nmap -sV -A 10.10.72.15 -p 22,80 and obtained the result shown above. The target machine is running a HTTP server on port 80. There is also an SSH application on port 22. Since the challenge mentions to target the HTTP on port 80, I will begin there.
Port 80: HTTP
The webpage above is displayed on port 80. Right away, I notice the target machine is running SPIP as the CMS. However, what application version is it? And what can I find by performing a directory search? I performed a basic directory search using ffuf but I did not find anything useful. I tried using different wordlists but I had no luck. Maybe I can find a tool to perform these scans for me?
On Google, I searched for SPIP scan and found the Github repository shown above. This tool is located at https://github.com/PaulSec/SPIPScan. Time to make a copy of the tool on my machine. To achieve this, I downloaded the project on my machine and installed the required packages. Time to run it against the target machine.
Firstly, I wanted to identify the application version. To achieve this, I ran the command python2 spipscan.py --website=http://10.10.72.15/spip --version and obtained the result shown above. The target machine is running the application version 4.2.0.
I did a Google search for any vulnerabilities for this version and found out it is vulnerable to unauthenticated RCE, as shown above. The exploit is verified too. This exploit is available at https://www.exploit-db.com/exploits/51536. Before running the exploit against the target machine, I wish to enumerate further.
I ran the command python2 spipscan.py --website=http://10.10.72.15/spip --sensitive_folders --verbose and obtained the information shown above. The tool successfully found a few interesting directories. The directory /config sounds the most interesting to me. But after digging through the directory, I did not find anything useful. The tool also found an interesting PHP fie.
One of the files located at /local called config.txt contains the result shown above. This file contains all the version of the packages used by the web application. Maybe one of these packages are out-of-date and exploitable? This leaves me with multiple attack vectors. Time to explore these possible attack vectors. I will first attempt using the exploit.
I downloaded a copy of the exploit from https://www.exploit-db.com/exploits/51536 on my machine. Then I saved the content of it to a file called exp.py, as shown above. However, I was unable to achieve a foothold on the target machine via this exploit. This vulnerability has the CVE ID of CVE-2023-27372. I fired up Metasploit and searched for this vulnerability and got a hit. There is an exploit module for this exploit at unix/webapp/spip_rce_form.
I used the exploit module and set the options shown above. The parameters I changed are LHOST to the IP of my machine, RHOSTS to the target machine 10.10.72.15, and the TARGETURI to /spip.
Running the option check shows the target machine is vulnerable to the exploit. Time to test it.
I ran the command run and gained a foothold on the target machine as the user www-data as shown above. This exploit successfully landed me a meterpreter session, but I opened a shell using the command shell. I tried to upgrade my shell to a tty shell, but Python is not installed on the target machine. Maybe there is a user on the target machine with SSH key?
After some manual enumeration, I found there is one user called think on the target machine as shown above. Browsing inside the directory of this user shows it has the SSH key with the name id_rsa. Maybe I can SSH into the target machine from my machine. I copied the content of the id_rsa to my machine inside a file called id_rsa. Then I modified the permission of the key using the command chmod 400 id_rsa.
Then I used the command ssh think@10.10.72.15 -i id_rsa to SSH into the target machine as the user think, as shown above. I successfully elevated my privileges from www-data to the user think.
Running the command find / -perm -u=s -type f 2>/dev/null shows an unusual binary with the name /usr/sbin/run_container. This binary has higher privileges somehow. I noticed strings is installed on the target machine.
Running strings /usr/sbin/run_container shows the result shown above. It seems to be executing the command /bin/bash /opt/run_container.sh. Can I read the content of /opt/run_container.sh? I am able to run the command cat /opt/run_container.sh, however, I am unable to edit the content of the script. After getting stuck for some time, I decided the to check the hint and obtained the hint: Look to the App Armor by it's profile..
Running the command env to check the environmental settings, I obtained the result shown above. Right away, I notice the user think is not using a bash shell. Instead, it is using ash shell. This is probably due to the App Armor.
To check the defenses on the target machine, I used the guide from https://book.hacktricks.xyz/linux-hardening/privilege-escalation#enumerate-possible-defenses. Firstly, I browsed to /etc/apparmor.d. Then I read the content of usr.sbin.ash and obtained the result shown above. The directories /dev/shm and /var/tmp do not have ** after its name; therefore, I have access to it.
Since I have access to /dev/shm. I can copy the bash shell to that directory. Then I can use that shell. To achieve this, I used the command cp /bin/bash /dev/shm first. Then I spawned the bash shell using the command /dev/shm/bash -p, as shown above. Now I can modify the /opt/run_container.sh file. To achieve this, I used vim. From the previous image, I can create a bash shell with chmod +s to spawn a higher privilege bash shell at /tmp.
Now the content of the /opt/run_container.sh contains the script shown above. Time to execute the run_container binary and spawn the higher priv shell located at /tmp. I ran the command run_container first.
Then I executed the command /tmp/bash -p to spawn a root shell. GG. Now I have a root shell on the target machine, as shown above :)
The two flags are shown above.